\section{PRAN Overview}
We design the PRAN architecture to satisfy the new requirements facing current RANs, 
then we present PRAN's use cases. We finally address its implementation
challenges.

\subsection{PRAN Architecture}
\begin{figure}[htb]
\centering
\includegraphics[width=0.4\textwidth]{./figures/PRAN.pdf}
\vspace*{-0.1in}
\caption{PRAN Architecture}
\label{fig:arch}
\end{figure}

PRAN's hardware infrastructure 
consists of remote radio heads (RRHs) 
%erran: RRHs are detached from base stations; 
%%in base stations
 distributed in a region, 
centralized commodity servers with DSP accelerators and high-speed interconnects 
between RRHs and servers. A RRH has antennas and analog components that convert 
received radio signals into digital samples (I and Q) in the uplink and turn received digital samples
into analog signals and transmits them over the air in the downlink. The
high-speed interconnects can be fibers or microwaves connecting RRHs with the cluster of
commodity severs. The commodity servers perform L1/L2 and other data processing in the 
RAN.

PRAN has 4 planes:
{\bf a radio plane}, {\bf a data plane}, {\bf a control plane} and {\bf a management plane}. 
The radio plane isolates radio resources among different operators.
The data plane includes data paths of UEs' data streams (a stream of bits processed by L1/L2 such
as transport block in MAC, code block in PHY, I and Q samples after modulation), and there can be 
multiple data paths in the data plane (e.g. different modulation schemes, MIMO
or not). 
%erran: make the data stream traverses
The control plane configures the data plane and directs each data stream through one of the
available data paths according to the environment (e.g. channel condition) or an operator's
policy (e.g. middleboxes, application types). Each base station's data plane and control plane are packed as a task; 
the management plane assigns computational resources (e.g. CPU cores) to tasks.

\subsection{Use Cases}
We present a few use cases for how one could use PRAN to solve problems in
current cellular network deployments.

{\bf New PHY/MAC.}
PRAN's modular design makes it easy to introduce new PHY and MAC protocols in
the data plane or control plane. For example, for the data plane, an operator
can reconfigure the symbol length, frame structure and physical channels. For
the control plane, an operator can reconfigure the scheduling algorithm to
support cross-carrier scheduling. Cross-carrier scheduling enables one carrier
to schedule transmissions of another carrier.  Operators can also introduce new
interference management algorithms.   

{\bf Flexible Data Paths.}
PRAN offers per-flow customization of data paths. For example, video
traffic uses Unequal Error Protection in the physical layer and subject to video
transcoding if there is congestion. Voice traffic is scheduled by the
semi-persistent scheduler instead of the dynamic scheduler. Voice traffic may go
through the echo cancellation function depending on the measured channel
quality. Voice traffic header must be compressed. 

{\bf Flexible RAN Sharing.}
Current LTE RAN sharing is controlled by a single entity.
In PRAN, each operator can have a RAN scheduler to 
directly control the radio resources of its own slice
so as to schedule transmissions and manage interference. 


\subsection{Challenges and Solution Overview}
%Designing the PRAN architecture has several challenges. We make use of the radio data processing properties to overcome them, and design %proper mechanisms to overcome them.
To realize a programmable RAN, we face several challenges. We leverage
properties of L1/L2 functions to design effective solutions. 

{\bf Challenge 1: Satisfy Time Constraint.} 
% deadline
In a RAN, many data operations in L1/L2 have very strict time constraints. For
example, a transport block (a sequence of bits from MAC layer to PHY layer) of a
subframe must be processed within the subframe's duration (1ms in LTE),
otherwise data will be backlogged in the MAC layer; a received transport block
must be acknowledged within a certain time interval (4ms in LTE), otherwise the
sender would regard that block as lost and retransmit it.  
%Software radio processing usually do not have as good performance as ASIC
%hardware, so it is challenging to satisfy the deadline %requirement in a RAN. 
It is challenging to meet deadline requirements if multiple UEs are processed in
parallel and many L1/L2 functions are performed in software. 

{\bf Solution:} While predicting the time needed to compute a function is hard
in general systems, most processing operations in L1/L2 take time proportional
to length of the input and are independent of the exact input (e.g. turbo
coding, FFT). Therefore we can easily predict the processing time 
%erran: redundant
%%(and CPU cycles) 
needed to process particular input. In a RAN, downlink and uplink data
transmissions are scheduled ahead of time and the resource requirements are
predictable, we can allocate computation resources to the processing operations
to satisfy a given deadline. As a further optimization, servers can have DSP
chips installed, so some data processing (e.g. turbo coding, FFT) can be
offloaded to hardware reducing processing time. 

{\bf Challenge 2: Handle Bursty Traffic.} 
%The L1/L2 processing of all base stations in a region is centralized, so 
Computational resources (servers) are shared by base stations, 
and downlink and uplink data transmissions are
scheduled at the subframe granularity (1 ms in LTE).  
%This makes it hard to do dynamic resource allocation per transfer (the time for
%state preparation can exceed the %time allocated for processing a single
%subframe) and handle bursty traffic. 
When bursty traffic comes, it is hard to reallocate computational resources
to busy base stations at fine granularity~\cite{tdlte}.
This is because the transport blocks and the state needed have to
be sent to other servers. This overhead is not
negligible~\cite{MACProcessor,maclets,zhang2012demo}.  

{\bf Solution:} Adapting to traffic patterns, we try to make the optimal
tradeoff between the amount of dedicated resources and shared resources to
minimize the total computational resources needed. Different UE's L1/L2 data
block processing can be performed independently. Offloading at the granularity of
per UE per data block makes it easier to use dynamic resources to meet deadline
requirements.   
%UEs' data processing in Layer 1 \& 2 is independent from each other, so they
%can be processed in parallel. If a base %station's processing deadline cannot
%be satisfied, it offloads some of its UEs' processing to idle resources
%(e.g. %an idle core or an idle server). 
%In this case the offloading time overhead plus the workload processing time
%should satisfy the time constraint. 
%\notepanda{This is very unclear: What is independent, the processing of each
%subframe, each UE, something else? Why %does offloading to idle resources not
%require state prepration. Essentially if the claim is we don't need much state
%%for layer 1 and 2 then maybe we should jsut say that?} 

{\bf Challenge 3: Provide Programmability.} 
%PRAN should allow fast and convenient technology upgrade and operators'
%customized data processing. It is necessary to design a framework%, language
%and interfaces to ease the evolution. Some RAN-specific programming
%requirements, such as time constraints, should also be %considered in the
%language/interface design. 
%% interface/language.
RANs should support the need for rapid change of L1/L2 functions and per
operator customization of data paths.  

{\bf Solution:} PRAN modularizes L1/L2 processing into blocks which are used to
implement basic processing. PRAN provides mechanisms for operators to program
and implement their own processing blocks. Operators are required to provide
both the code and timing constraints for these blocks, the timing constraints
can then be used by a scheduler to drive processing. Further, we envision
providing a compiler that is capable of targeting multiple backends (i.e., x86,
DSPs, FPGAs, etc.) and can use this compiler to allow the scheduler to place
processing blocks on a variety of
hardware\cite{programming,neel2005formal,zhang2011trump,zhang2013enabling}. 

\eat{To make it easy, a domain specific language (DSL) is needed. A DSL should
  automatically optimize and parallelize L1/L2 functions depending on the what
  backends are available (accelerators of certain functions, full L1 in DSP, no
  DSP, etc).   

{\bf Solution:} PRAN modularizes the L1/L2 processing into blocks, which
implement basic  
processing functionality. A scheduler makes decisions of the data path that
the UE data traverses. PRAN also provides interfaces for the interaction between
the processing blocks and the scheduler. Operators can implement their own
processing blocks to achieve technology upgrade and customized services. The
interface takes time constraint into consideration, which  
is passed to the resource manager by the compiler.
\noteerran{this part is not very clear}}

